Typical file caching methods include a cache receiving a file from a file server, and storing the entire file. Later when a client desires the file, instead of serving the file from the file server, the file is served from the cache. Because the cache is typically a server that is closer to the client, or has higher bandwidth than the file server, the file is served to the client quickly from the cache.
The application of typical file caching methods to files that include streaming media data, for example Video on Demand (VoD) files, can lead to new problems. VoD systems generally either stream content through a set-top box, allowing viewing in real time, or download it to a device such as a computer, digital video recorder, personal video recorder or portable media player for viewing at any time. The data delivered by networks delivering such content can run to very large amounts, and caching can be particularly useful.
This can be understood with reference to FIG. 1, which is a schematic illustration of an exemplary architecture of a VoD system with deployed caches used to reduce the load on a central long-tail server. In the example, it can be supposed that the network uses Real-Time Streaming Protocol (RTSP) streaming, where the payload is transported over the User Datagram Protocol (UDP) in Real-Time Protocol (RTP) packets, but it will be appreciated that many other applications and protocols have a similar architecture and will have similar issues.
The architecture of FIG. 1 includes a network 100 having a streaming server 101 and a number of caches 102-106. Clients 107-109 are configured to receive files and/or streaming data from the server 101 or the caches 102-106. The clients use RTSP to set up and control streams of RTP packets. This includes the negotiation of codecs, bitrates, ports etc for the resulting RTP stream. With RTSP the clients can start and stop the streaming, or fast forward or rewind the streamed media clip.
RTP packets are sent in sequence with a sequence number to tell the client the order of the packets. This infers a state into the protocol that the streaming server 101 needs to maintain and increment for each data packet it sends out. The sequence number is also used by the clients 107-109 to detect packet loss which is reported back to the streaming server using the Real-Time Transport Control Protocol (RTCP).
In order to reduce the load on the streaming server 101 and to save bandwidth in the delivery network 100, some of the content is stored in caches 102-106 closer to the end users 107-109.
The example of RTSP streaming for VoD highlights one problem with caching in general—namely that the caches 102-106 themselves need to understand the protocol and the application. The fundamental principle of a cache is that, when it takes over the role of the central server, it needs to understand the same protocol that the server understands, and know and maintain all required states etc. This applies whether the role of the central server is taken over transparently through re-routing with deep packet inspection, or through other means in the form of some redirection such as DNS based redirection or any redirection given by the protocol. If caching is to be deployed for many different applications, or if the server or protocol is enhanced or upgraded, it is also necessary to upgrade and maintain the caches. It is often the case that there is one cache per application: for example there may be a HTTP cache, a P2P cache and an RTSP cache. In some networks, such as mobile networks for example, caches can be placed in places that are hard to reach. If an upgrade of functionality is needed whenever a new application is deployed this can be costly.
Additional problems may arise if there is mobility in the network so that the client can move around during a session (such as a mobile terminal moving between base stations). Using the example above, suppose one of the clients 107 is receiving data from one of the caches 104. If the client 107 moves location so that it is now receiving data from another cache 105, the session state (in this example, the RTP packet sequence number) needs to be migrated into the new cache 105, which may or may not also include the relevant content, so that the session can continue in the new place. A great deal of application specific knowledge is therefore required in the cache implementation.
Where caching is controlled by a redirector-based system, it is possible to balance load (i.e. cache allocation and request distribution) between caches. However, this is a non-trivial issue if the caches are geographically distributed. It is also not simple in a distributed system to find the cache that has the given content, which generally requires complex solutions for synchronization.
Furthermore, in many of the solutions used today (including redirector-based solutions) there is a chance that communication is disrupted if the cache server fails. A solution that allows seamless fallback to the original communication would be desirable.